Most software provides customers with a migration mechanism that is used to enable customers to use new features and to get benefits from high performance that the software provides in a higher release. One of the most important parts of migration is database migration, which may be split into two parts: DB schema migration and data migration. DB schema migration includes the migration of tables, views, columns, indexes, primary keys, foreign keys, triggers, etc. In the course of the test of IBM® WebSphere® Commerce migration performed by the inventors, customers often provided feedback that DB migration failure happened on a customized DB schema. The problems are at least one of the following:
Problem 1. Something was lost in the customized database schema after the DB migration. For example, assume that customers defined a column C on a table T (T is not the customized table). During the migration to the higher release of the product, the table T was dropped or recreated. Meanwhile, the column C was lost.
Problem 2. The customized database schema conflicted with the new release's schema. For example, assume that customers defined a table T in a previous release. The new release also has a table named T. In this case, the difference of the table definitions between the customized one and one in the new release are ignored during migration.
In the present, there is no efficient method to detect conflicts before migration and verify the customized schema migration.